Small portable computing devices have become ubiquitous. It is now common to see people reading their email, reviewing documents and performing various other tasks on the bus, the subway, in the park, in restaurants and just about anywhere else, using an ever-expanding range of devices. Some devices resemble personal digital assistants (PDA's), others include cellular telephone and other wireless communications functionality, and still others (e.g., the Apple IPAD) take the form of tablet computers. Business and other organizations and enterprises have embraced such technologies because of the increase in productivity and flexibility they can provide to employees and consultants.
As the variety of such portable devices has become more diverse, so have the challenges associated with enterprise or other centralized management of such devices. Security and configuration managers can use device-appropriate policy management protocols and policy servers to manage devices that connect to their networks to maintain network security, manage use of resources, detect or prevent misuse, control access to information using various policies for the different device types in use. To facilitate this, some enterprises try to standardize on only one type of handheld device that will be supported. However, end users often pressure their employers and IT specialists to support various devices. Since many users are not willing to carry multiple devices, users often end up using the same handheld device for both business and personal use. Such dual usage can create a host of management channels for enterprise IT personnel who need to be able to carefully manage and safeguard information belonging to the enterprise without comprising the user's own personal information.
Existing policy-based systems typically enable authentication of devices attempting to access the network, verifying required device configurations, and blocking access to and reporting access attempts by devices that are not authorized or configured as required by policy.
Policy Management
Policy management provides a range of powerful tools to enable or effect devices and device capabilities. Generally speaking, policies comprise one or more policy elements that each define one or more aspects of a device's configuration and/or permitted access modes. Policies are defined in various ways, depending on the device type they apply to, the policy server used to install them and/or to verify device compliance with them. Policies are typically disseminated from policy servers, which act as a source of policies for transport to the devices they apply to, using various policy management protocols. Policy management protocols may comprise protocols for interaction between policy servers and devices receiving policies. These protocols can provide means not only to transfer the policy to the receiving device or devices, but also to manage policies on those devices, such as by verifying that the policy has been received by the device, verifying device compliance with the policy, removing the policy, updating the policy, or other policy-related activities. The manner in which these functions are accomplished varies from one policy management protocol to another, and the functions supported also vary.
Applying a policy to user devices can be challenging for a variety of reasons, such as the plethora of mobile device types from various manufacturers, a plurality of management protocols developed by different device vendors for setting and verifying device parameters, and inconsistency between device manufacturers in the device configuration elements that are exposed and the device configuration elements that can be managed by the policy management protocols supported.
Policy management systems traditionally manage policies and data separately, and prior art policy management systems typically provide both policy and policy enforcement agents for policy, and data and data management applications for data.
In some cases, aspects of device functionality that it is desirable to manage are not supported by the policy mechanisms supplied by the device manufacturer or the on-device policy capabilities. For example, it may be desirable to remotely cause the deletion of specific information or types of information from the local storage on the device without affecting other information or types of information. This may not be possible if the policy protocol or on-device protocol support software permits only an all-or-nothing deletion mechanism, where all on-device data can be deleted under policy control, but there is no way to delete only selected information.
Policy management protocol implementations or “policy transports” are sometimes embedded within a broader data stream, such as where policy and data are passed between an applications server and a user device. Well known policy transports include, for example, Microsoft ActiveSync™, BlackBerry™ Policy Service (BPS), Open Mobile Alliance™ (OMA) Device Management (OMA-DM), and Apple iPhone™ Configuration Utility among others. In some implementations, specialized software must be installed on a user device in order to enable the device to interoperate with a specific policy transport. This is inefficient and adds to deployment cost and complexity. When aspects of device operation that are not supported by a policy transport for a given device must be managed, additional specialized software may be required, thus compounding the problem. It would be advantageous to permit accomplishing the unsupported aspects of policy enforcement without such additional specialized software, such as by repurposing device or device software capabilities not specifically intended for policy enforcement. The following is a non-exhaustive survey of some such available technologies that include various degrees of policy management:
1.1.1 Microsoft Exchange ActiveSync™
Microsoft Exchange ActiveSync™ (EAS) is a protocol for connecting mobile, portable and other devices to Microsoft™ Exchange servers, allowing synchronization of e-mail and PIM (Personal Information Manager) data, such as tasks, calendars, and contacts, between Microsoft™ Exchange and the mobile device as well as limited policy management of the device by Microsoft™ Exchange.
Microsoft™ has implemented the EAS protocol on Microsoft™ Windows Mobile™ devices, and has licensed the protocol to third-parties for use with other mobile operating systems. Licensees include Nokia Symbian S60™, Sony Ericsson UIQ™, and Apple iPhone™, handset OEMs such as Motorola™, HTC™, and Samsung™ and third party synchronization vendors such as DataViz™. These vendors license and implement the client-side EAS Application Programming Interface (API).
The EAS protocol may include three relevant areas of processing: Handshake, E-mail/PIM Synchronization, and Policy Push. The term “push”, as used herein, refers to a method of data or command transfer where a server initiates an exchange with a client. The opposite of a “push” is a “pull”, where the exchange is initiated by the client. “Pull” is sometimes referred to as “polling” when a pull operation is performed on a periodic basis.
Handshake: Although EAS supports push e-mail from a server, EAS depends upon the mobile device to initiate the connection to the server. It is the device's responsibility to connect (and re-connect, if a connection is lost) to the server, to create the session over which e-mail, PIM, and policy information can be pushed. Establishment of a session generally involves an authentication handshake, which identifies the device user (by Active Directory™ (AD) Username) and the device (by EAS Device ID and EAS Policy Key) to the Microsoft™ Exchange Server, associating the session with a mailbox for the purpose of e-mail and PIM synchronization, and with a user and an AD group for the purpose of policy push. The EAS Policy Key is used as a first stage check to prevent continued communication if the Policy Key is not provided or is not valid. The user is authenticated either by passing the user's AD password in the protocol, or by using a client or machine certificate for client-side authentication.
E-mail/PIM Synchronization: Both the device and the Microsoft™ Exchange server can “push” new (or changed) information to each other. For example, new e-mail can be pushed from Microsoft™ Exchange to the device. New or modified contacts, calendar entries, and other PIM information can be pushed as well. E-mail sent from the device is pushed to the Microsoft™ Exchange Server, as well as PIM information created or changed on the device. The protocol specifies mechanisms for keeping changes synchronized between Microsoft™ Exchange and client devices.
Policy: The Microsoft™ Exchange Server can also push policies to the device. These policies can comprise actions such as “Device Wipe” which causes the device to clear its local storage and return the device configuration to its original factory state. Other policies can specify use of secure operation features, such as a requirement that the device lock itself after a period of (user) inactivity and require from the user a password or PIN of certain complexity to unlock. The device acknowledges receipt of such policies, so Microsoft™ Exchange can assume that the policy has been enforced.
1.1.2 Synchronization Using Microsoft Exchange ActivSync
In the Exchange ActivSync (EAS) protocol, synchronization is the process of reconciling differences between data that is stored on a client (such as a mobile device) and data that is kept on a server, such as a Microsoft Exchange server. Both the client and the server maintain their own copies of data and keep track of changes that have been made since the last time the two were synchronized. The client initiates synchronization by sending a sync command to the server to request that the server respond with updates. The server processes any updates that it receives, resolves any conflicts, and sends the list of changes back to the client, which updates its local copies to match.
The EAS protocol also provides a monitoring mechanism, “ping”, that enables the client to request notification if specific folders on the server are changed, such as when a new e-mail message arrives in a folder. Because all synchronization is initiated by the client, the mechanism uses a ping-to-pull model in which the server sends a notification of the change to the client, and the client responds by requesting synchronization.
All communication between the client and server is initiated by the client. When the client communicates with the server, the client sends a request to the server as an HTTP POST message, using UTF-8 encoding. The server then sends back a response to the POST message. The request and response each have a header and a body (which may be empty). Each POST message contains a single command, such as a sync or ping command.
Before a folder can be synchronized, an initial synchronization key must be obtained from the server. The client obtains this synchronization key by sending the server an initial synchronization request where the synchronization key is zero. The server responds with updated data and a new synchronization key value, which is generated by the server for each transaction. The client stores the returned synchronization key and specifies it with its next synchronization request. To perform a full re-synchronization, the client deletes its local copy of the data in a folder and then requests synchronization with a synchronization key value of zero (0) to get the current data from the server.
The foldersync command synchronizes the folder list between the client and the server, but does not synchronize the data in the folders. Foldersync works similarly to the sync command. An initial foldersync command with a synchronization key of zero is required in order to obtain the list of folders and the synchronization key associated with that list. The returned synchronization key can be used in subsequent foldersync commands to obtain folder list changes from the server. A list containing all folder specifications is returned to the client when a foldersync is done with a synchronization key of zero.
1.1.3 BlackBerry™ Enterprise Server
BlackBerry™ Enterprise Server (BES) is a push-based server from Research In Motion™ (RIM™) that enables a secure, centrally managed link between BlackBerry™ devices and an organization's enterprise systems, applications, and wireless networks. It integrates with popular content sources such as e-mail and personal information management (PIM) systems such as IBM Lotus Domino™ and Microsoft™ Exchange, and is designed to provide secure access to e-mail, organizer data, instant messaging, Web browser, and other enterprise applications. It provides this access by retrieving information from enterprise content sources and “pushing” this content to a BlackBerry™ mobile device. In addition to applying policies to individual devices, administrators can create groups of mobile devices, then apply policies for one or more groups. Approximately 450 different policies can be applied to individual devices or groups of BlackBerry™ devices, ranging from enforcing password protection and controlling access to third party mobile applications, to controlling the use of certain device features, such as use of the camera or making video recordings.
1.1.4 Open Mobile Alliance™ Device Management
The Open Mobile Alliance™ (OMA) Device Management (DM) specification is designed for management of small mobile devices such as mobile phones, PDAs, and palm top computers. Device management includes, for example, provisioning, configuration, software installation or upgrade, and status reporting. A device may implement all or a subset of these features. Since the OMA-DM specification is intended for use with mobile devices, it is designed with sensitivity to memory and storage space limitations, communication bandwidth constraints, and security.
OMA-DM uses Extensible Markup Language (XML) for data exchange; specifically the sub-set defined by Synchronization Markup Language (SyncML). Device management is through a client-server relationship between a server and the client device being managed. OMA-DM is designed to support and utilize a variety of connection methods, such as Universal Serial Bus (USB) or RS-232 wired connections and wireless connections, such as Global System for Mobile communications (GSM), Code Division Multiple Access (CDMA), Infrared Data Association (IrDA) or Bluetooth. Transport can involve Website Project (WSP) or (Wireless Application Protocol (WAP)), Hypertext Transfer Protocol (HTTP), OBject EXchange (OBEX) or similar transport layers. Policy settings can be transferred in OMA Device Management Files (DDF), which are XML data files of known format.
The communication protocol used by OMA-DM is a request-response protocol. Authentication and challenge of authentication are included to ensure the server and client are communicating only after proper validation. The initial message from the server to a client is in the form of a notification, or alert message. Once the communication is established between the server and client, a sequence of messages is exchanged to complete a given device management task. OMA-DM provides for alerts, which are messages that can occur out of sequence, and can be initiated by either server or client. Such alerts are used to handle errors, abnormal terminations, etc.
The protocol specifies an exchange of “packages” during a session. The packages consist of several messages, and a message in turn consists of one or more commands. The server initiates the commands and the client executes the commands and returns the results in a reply message. In some instances, the command includes policy elements to be set on the device. In others, the command reports aspects of the device's configuration status back to the server.
1.1.5 iPhone™ Configuration Profiles
iPhone™ Configuration profiles define one or more iPhone™ settings. Configuration profiles are XML files that contain device security policies and restrictions, virtual private network (VPN) configuration information, Wi-Fi™ settings, e-mail and calendar accounts, and authentication credentials that permit devices to work with enterprise systems. Configuration profiles can be installed on devices connected via USB using the iPhone™ Configuration Utility, or configuration profiles can be distributed by e-mail or through a webpage. When users open the profile e-mail attachment or download the profile using the Safari™ web browser on their device, they are prompted to begin the Configuration profile installation process.
1.1.6 Some Policy Enforcement Mechanisms
Generally speaking, previous policy enforcement mechanisms block access and/or usage rights to specific services on a network, or require the performance of a specific action on a policy-managed device. See as one example RFC2748—The COPS (Common Open Policy Service) Protocol. The first case (blocking) generally does not enforce the policy against specific data already on a policy managed device, and the second (requiring specific action) generally requires specialized software on the policy managed device, such as a policy enforcement agent. Both suffer drawbacks from their respective implementations.
The model of wiping all data from a mobile device upon termination of an employee is becoming increasingly problematic. Many mobile devices store information belonging to more than one user or organization, for example when a mobile device, such as an iPhone, is used in both a personal and a business capacity. Many of the current generation of “smart mobile devices” are employee-owned but used in work activities as well as in their personal lives. When some devices have such mixed uses and contain data owned by an organization as well as data the organization has no rights to, while other devices are used exclusively for organization purposes and are organization-owned, organizations need both the ability to selectively delete data, such as wiping the contents of the device e-mail client folders used for work activities and the ability to fully wipe the entire device. While most devices today incorporate a full-wipe capability as part of their normal security profile support functionality, the ability to selectively wipe only some of the data stored in a device is typically absent and requires the provisioning of specialty software on the mobile device to accomplish the selective wipe task.
Not infrequently, mobile devices are misplaced or stolen. In other cases, an employee will leave the company's employment with a personal device that has been connected to the corporate network and contains corporate data, such as e-mails containing proprietary information (e.g. e-mail addresses, customer data, project plans, etc.). With the multitude of situations that an organization may have to contend with, it is important for the organization to have a flexible capability for removal of confidential information from a mobile device without having to wipe the entire device.
If a mobile device is lost or stolen, it is important to be able to remotely wipe the device fully and restore it to factory defaults. Prior art methods exist to identify an individual device, remotely wipe the entire device and restore it to factory settings, and to deny further access to an organization's network resources by that device. Current solutions typically push a specialty command, called a “remote wipe”, to the mobile device. This command causes the mobile device to remove all stored information and essentially returns the mobile device to the state it was in when it left the factory. This approach to wiping organizational information is very useful; as mentioned earlier, organizational data can exist in many places throughout the mobile device. It thus becomes important to have the capability to ensure that all organizational information can be wiped from a mobile device. Most or many current devices support such a capability.
While many use cases are served by fully wiping a mobile device, a full wipe may not always work as intended. For example, a full wipe does not work when a mobile device is configured with a firewall or other component that blocks the receipt or functioning of the “remote wipe” command. Similarly, disabling the mobile device-specific specialty client software can disable the “remote wipe” commands in devices making use of such specialty client software. In some devices, the process of performing a full wipe is not accomplished in a short time, and the device can run out of power and shut down before the wipe is complete.
Additionally, the need to selectively wipe portions of a mobile device comprising e.g., only those portions of the stored information belonging to the organization is needed, such as in cases where the device is not owned by the organization and a full wipe is inappropriate. For example, when an employee leaves an organization, the organization may want to focus on removing organizational e-mail and documents from the mobile device instead of wiping out the ex-employee's personal information, like music or family photos.
As will be clear from the disclosures below, exemplary illustrative non-limiting implementations are useful for meeting such needs without necessarily requiring specialty software to be present on the policy managed mobile device.
Non-limiting aspects of the technology herein relate to methods, systems, and devices for implementing one or more data management policies from an integrated policy server and/or one or more policy services to a mobile device that does not necessarily have a resident policy enforcement agent or application operating sufficient to enable all aspects of the policy.
An exemplary illustrative non-limiting method preferably comprises intercepting a data stream between a data server and the mobile device, identifying the mobile device, identifying a policy in an integrated policy server applicable to the mobile device based on the identity of the mobile device, the policy including one or more policy elements, identifying one or more of the policy elements based on the mobile device, and translating the policy elements into actions involving the data stream between the data server and the mobile device so as to implement at least one aspect of the identified policy. The actions can comprise permitting normal exchange of data between the data server and the mobile device, preventing communication between the data server and the mobile device, or modifying the data stream between the data server and the mobile device.
The method may further include one or more of the steps of removing one or more data elements from a data stream, adding one or more data elements to a data stream, and/or translating one or more of the policy elements into a form transmittable by one or more of the data streams.
One non-limiting aspect of technology herein is related to the policy-managed intermediation of data streams between a policy managed device and one or more servers, where the intermediation takes the form of translating one or more policy specifications into commands or instructions within the data stream that have the effect of enforcing the policy specification upon the mobile device. These commands and/or instructions are processed by the policy managed device using extant capabilities present in the managed device, typically in the software used to process the data stream, and do not necessarily require or use additional special purpose software on the mobile device. Thus, the requirement for any additional policy enforcement components on the mobile device can be eliminated, reducing the complexity of the mobile device configuration.
Furthermore, by repurposing the software used to process the data stream to also provide policy enforcement, the ability to prevent policy enforcement is reduced. Interference with policy enforcement requires that the data access software be prevented from functioning, which also prevents data access. Retaining ability to access the data is effective in enforcing the policy. Thus, the commands and/or data inserted into the data stream are effective for enforcing the policy intent on the policy-managed device.
In some exemplary illustrative non-limiting implementations, a policy proxy component intercepts communications between a mobile device and at least one server. Based at least in part on policy elements provided by a policy server, the policy proxy either permits communication between the mobile device and the one or more servers or limits communication between the mobile device and the one or more servers.
When required by the policy provided by the policy server, the policy proxy inserts, removes or substitutes data or commands in the communication stream to the mobile device that cause the mobile device to delete at least some of the data it has stored in its local data storage subsystems. When required by the policy provided by the policy server, the policy proxy inserts, removes or substitutes data or commands in the communication stream to the mobile device that cause the mobile device to delete all of the data it has stored in its local storage components. When required by the policy provided by the policy server, the policy proxy can also alter the configuration of the mobile device and/or the configuration of one or more servers, network devices or other components required for access to the policy-protected network so as to prevent the mobile device gaining access in the future.
The functionality of the policy proxy can be implemented in a variety of arrangements, such as with a separate network device, by embedding the functionality into an existing network device, such as a network router, switch or firewall, by incorporating the policy proxy functionality into a policy server system, into each server that connects to mobile devices directly or indirectly, in a virtual machine or network appliance, or by any other appropriate mechanism.